Authentication and Authorization Frameworks: OpenID and SAML

Learn the process through which OpenID and SAML provide authentication and authorization.

Introduction#

Picture the following situation. A person who wants to watch a movie buys a ticket for it. The movie ticket will allow entry to its holder, but it won't contain any information about the said holder except for the movie they're authorized to watch. So, anyone can use the ticket, even if they weren't the rightful owner, because there's no way of verifying the holder's identity. In this example, we assume OAuth 2.0 functions like a movie ticket; it only provides authorization and needs further security methods to implement sufficient authentication.

To tackle this vulnerability, this lesson details the following authentication and authorization frameworks:

  • OpenID Connect (OIDC):  It's an authentication framework that typically works alongside OAuth 2.0. It’s an open standard and enables its users to log in to multiple applications or websites with a singular set of credentials, removing the need to keep different information for various sites. It allows user authentication without needing applications or websites to store user data.

  • Security Assertion Markup Language (SAML): It’s also an open standard and is typically deployed in enterprises. It's both an authentication and authorization standard that allows users to access numerous applications using a singular set of credentials. Through SAML, entities can both authenticate and authorize information access from different domains in a secure way.

Let's begin by expanding on OpenID Connect.

Note: OpenID Connect largely performs the same operations as OpenID, but does so in a more API-friendly manner. Therefore, in our context, we'll focus on OpenID Connect.

OpenID Connect (OIDC)#

OpenID Connect (OIDC) typically works alongside the OAuth 2.0 framework and provides an authentication layer that sits on top of the OAuth 2.0 protocol. It enables applications to verify the identity of the end users by obtaining their basic profile information through the use of ID tokens.

This process follows the same flow as OAuth 2.0 mentioned in an earlier lesson, but along with the access token, an ID token is also provided. The users can access multiple applications using the same ID token, which is also known as SSOs. The application then uses the access token and ID token to make requests for data in the resource server.

An ID token is sent along with the access token
An ID token is sent along with the access token
Question

What is the difference between access tokens and ID tokens?

Hide Answer

The purpose of access tokens is to be utilized in OAuth for the purpose of making requests for an API’s resources. On the other hand, ID tokens are used in OpenID Connect, which proves the client has been authenticated. Although this is not a requirement of ID tokens, they also usually contain information about the client’s credentials, which access tokens do not. Format-wise, ID tokens are exclusively represented with JWTs, while access tokens may be in any string format. Access tokens also aren’t meant to be examined by the receiving application, whereas ID tokens are because they’re meant to be used by the application.

This framework makes authentication seamless for developers across websites and apps without having to manage their passwords, which can lead to security concerns. When OAuth 2.0 is utilized with OIDC, it enhances the overall security and reliability of the process, while also enabling SSO functionality. This eliminates the need for frequent transmission of sensitive user credentials, thereby mitigating the risk of several types of attacks.

Note: OIDC differs from OAuth 2.0 in that the latter is used to protect user resources, whereas the former is used to produce secure sign-in experiences by authenticating who the user is.

The advantages and disadvantages of OIDC are as follows:

OIDC Advantages and Disadvantages

Framework

Advantages

Disadvantages


OpenID Connect


  • SSOs streamline logging in to a variety of applications
  • Can be used in both mobile and desktop applications



  • Doesn't authorize on its own. Functions on top of OAuth 2.0
  • Considered less secure than its alternatives (susceptible to phishing attacks)
  • Doesn't have global integration to the extent of OAuth and SAML


SAML 2.0#

Security Assertion Markup Language, or SAML for short, also allows the user to access multiple applications with a singular login by using SSOs. It has both authentication and authorization capabilities in its process of exchanging user data between entities. Its updated version, SAML 2.0 was released in 2005. It’s built on top of the XML format and is widely used in government and enterprise applications. SAML centralizes authentication and authorization to increase security by eliminating the need to store passwords on the application server. Therefore, SAML introduces an identity provider (IDP), which serves as a trusted entity between a client and a service provider.

The working of SAML is shown in the following slides:

Created with Fabric.js 3.6.6
Trust relationship between IDP and various applications

1 of 6

Created with Fabric.js 3.6.6
The client wishes to access the service provider

2 of 6

Created with Fabric.js 3.6.6
The client isn't authenticated and is redirected to the IDP

3 of 6

Created with Fabric.js 3.6.6
The client authenticates into the IDP

4 of 6

Created with Fabric.js 3.6.6
The client is provided with the SAML assertion

5 of 6

Created with Fabric.js 3.6.6
The server accepts the client by verifying it's SAML assertion

6 of 6

The SAML 2.0 process can be condensed into the following steps:

  1. The application (service provider) the client wishes to access has a trust relationship with the IDP.

  2. A client wishes to access a service provider.

  3. Since it isn't authenticated, it’s sent to do so in the IDP. It most commonly authenticates itself by signing in with its credentials.

  4. Once authenticated, the IDP generates a SAML assertion

  5. The SAML assertion is sent to the client.

  6. The client forwards the SAML assertion to the service provider. The service provider receives the SAML assertion and maps it to its own user storage using a defined user identifier, such as an email address. Since there is a trust relationship between the service provider and the IDP, the client is allowed access to the application after the service provider verifies the assertion it received. The same SAML assertion can be forwarded to several service providers that the IDP has a trust relationship with, allowing the client access to multiple applications.

  7. Google implements SAML 2.0 to implement its SSOs between its individual applications or resources for both authentication and authorization purposes. It reduces the need for repeated sign-ins, which is particularly useful for an entity such as Google, which has numerous related applications in its possession.

Point to Ponder

Question

How is the trust relationship established between the IDP and the service provider?

Hide Answer

The service provider and the IDP both possess an XML file that contains the metadata and certificates of the entities. This metadata contains information about the configurations and rules that each assertion must follow. They exchange these metadata files to make certain both sides are configured the same which ensures that the server is able to map the users to its own database. The metadata also holds certificates and public keys for the entities, which are utilized to increase the security of the data transfer between the IDP and the service provider. This exchange of metadata establishes trust between the entities.

The use of SAML 2.0 increases security by eliminating the transmission of additional credentials. This reduces the chances of identity theft, phishing, and spoofing. SAML also increases the speed of application access because the user doesn't have to type in their details to log in, which in turn reduces administration costs to store credentials in the server. To its detriment, SAML isn't designed for modern application types such as SPAs and mobile applications, so consumers tend to lean toward other frameworks (OAuth 2.0 and OIDC) for these purposes. Implementing SAML in SPAs and mobile applications is possible but will lead to security gaps that'll be difficult to overcome. It's also considered more complex when compared to OAuth 2.0 because its process is more complicated to implement, and the size of the exchanged assertions is significant due to XML's inherent complexity. Another drawback of SAML is that it’s vulnerable to man-in-the-middle attacks because an attacker can intercept the SAML assertion and pretend to be the legitimate user.

SAML is mostly used in large enterprises to implement SSOs in B2B (business-to-business) and B2E (business-to-employees) applications. OAuth and OIDC are gaining popularity in recent years, especially in B2C (business-to-consumer) applications, but SAML is still relevant two decades after its inception.

These three frameworks can be compared in the table below:

Framework Comparison

Framework

Advantages

Disadvantages

Format

Developer




OAuth 2.0


  • Eliminates weakness of password authentication and allows access to resources for a limited time
  • Can be used in both mobile and desktop applications
  • Widespread in the API landscape and easy to implement






  • Doesn't authenticate on its own





JSON




Twitter and Google



OIDC


  • SSOs streamline logging in to a variety of applications
  • Can be used in both mobile and desktop applications



  • Doesn't authorize on its own Functions on top of OAuth 2.0
  • Considered less secure than its alternatives (susceptible to phishing attacks)
  • Doesn't have global integration to the extent of OAuth and SAML




JSON



OpenID Foundation



SAML



  • Employs SSOs for multiple logins
  • More practical for enterprises



  • Not designed for SPAs or mobile applications
  • Increased complexity when compared to the other frameworks




XML



Oasis

Quiz

2

(True or False) SSOs can increase the security of a system.

Your Answer
A)

True

Explanation

It increases the security by reducing repeated transmission of user information.

B)

False

Question 2 of 22 attempted

In this lesson, we examined two protocols, one that functions on top of OIDC to provide both authentication and authorization, whereas the other provides both on its own. Both are valid options when it comes to API design, and their advantages and disadvantages must be compared when debating which framework to implement in our system. If our API communicates with SPAs and mobile applications, OIDC with OAuth is the best way to implement both authentication and authorization. However, OIDC isn't as widely supported as SAML and we may prefer the latter in those cases where this becomes an issue.

OAuth: The Authorization Framework

High-Level View of Security in APIs